1. The Field of the Invention
The present invention relates to verifying measurable aspects of a module. More specifically, the present invention relates to verifying measurable aspects of a module to determine if a module is appropriately configured, for example, to access a resource or to issue challenges to other modules.
2. Background and Related Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, and database management) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices can transfer electronic data. As a result, many computerized tasks (e.g., voice communication, accessing electronic mail, controlling home electronics, and Web browsing) include electronic communication between a number of computer systems and/or other electronic devices via wired and/or wireless computer networks.
Some computerized tasks require limited interaction between modules at different computer systems. For example, an electronic mail client can query an electronic mail server for a user's electronic mail messages. When electronic messages are present at the electronic mail server, the electronic mail server can return the electronic mail messages in response to the query. However, this is a simple request/response mechanism and requires little, if any, additional interaction between the electronic mail client and electronic mail server
Other computerized tasks can require more tightly integrated distributed components. For example, some mechanisms require a number of modules at different networked computer systems (often referred to as “distributed components”) to implement more complex interactions of a single application (often referred to as a “distributed application”). For example, a unified inventory application may require more complex communication between a number of distributed components at different branch offices to appropriately reflect the number of items in stock for a company.
Often, for example, when transferring confidential or financial data, it may be desirable for computing systems to communicate with one another in a secure manner. Accordingly, computing systems can authenticate and agree on the mechanisms used to secure the data (e.g., electronic messages) transferred between the computing systems. For example, two computing systems may use the Secure Sockets Layer (“SSL”) protocol to establish a secure connection between one another. Further, it may be desirable for an application at a first computing system to prove proof of identity to another application at a second computing system (either in combination with or separately from computer system authentication). For example, a banking client may require that a corresponding server banking server prove its identity before the banking client will transfer financial data to the banking server. Proving the identity of an application can be done in accordance with Web service specifications, such as, for example, WS-Security and WS-Trust.
Unfortunately, there are typically no mechanisms for one distributed component to authenticate the actual instructions (code) that make up an application at another distributed component. That is, there typically are no mechanisms for a first distributed component to validate the bits of an application as stored on disk or in system memory of second distributed component that is in communication with the first distributed component. For example, even when a computer system and service are appropriately identified, there is no way to determine if the service will operate as intended. Thus, a user or programmer with access to authentication information for the service (a bank server) could alter the service for some malicious purpose (e.g., to intercept financial data) and yet still authenticate the service to external programs.
Unauthenticated code may be especially problematic when occurring among distributed components included in a distributed system. For example, some distributed systems may have a number of components that are specifically designed and tested for compatible operation and/or that are sold together and subject to a uniform license agreement. However, one distributed component may have no way to determine that another distributed component is in fact a licensed component and/or that another distributed component was designed and tested for compatibility. For example, an emulator, or “knock-off”, can mimic protocols used by a distributed component to appear as a designed and tested distributed component. However, emulators that have not been designed and tested for compatibility may cause other components of the distributed application to malfunction, cause security vulnerabilities or breeches, or otherwise operate inappropriately. It may also be that the use of an emulator violates a licensing agreement.
There is also often no way for one distributed component to determine the execution environment (e.g., operating system, hardware components, etc.) associated with other distributed components. Distributed components may be tested and specifically configured for use is specific execution environments (e.g., protected or secure compartmentalized environments). However, since a distributed application may include many distributed components that execute at different locations (logically and/or physically) there is always some chance (e.g., due to improper installation or administration or as a result of hacking) that a distributed component is executed outside of an appropriate execution environment. A distributed component executing outside of an appropriate environment can cause other distributed components to malfunction or otherwise operate inappropriately. Accordingly, what would be advantageous are mechanisms for validating distributed components and for preventing interaction with distributed components that have not been validated.